The act of writing and modifying software often introduces errors, termed “bugs,” in software code. Generally, software programmers use “debugger” programs to analyze and find these errors. Typically, these debugger programs permit placement of breakpoints within software code to stop operation of the code at specific points of interest. After reaching the breakpoint, the programmer may review variable values, make changes to the code, or step through the subsequent code instruction by instruction.
However, typical breakpoint methods perform poorly for embedded systems with limited physical memory. In applications where virtual memory is used, parts of a program are paged into the physical memory from a source. In these applications, it is difficult to set software breakpoints because a particular page of a program may not be in memory, and breakpoints may be lost when a page is transferred in and out of the physical memory.
Traditional breakpoint methods also work poorly for multithreaded systems. Typically, when a breakpoint is set, the debugger also identifies a thread to which the breakpoint applies. When the program is run, the system stops at the breakpoint and performs a test to determine whether the breakpoint applies to the thread in which it was found. This test may be performed many times during a debug session, leading to slow performance. In addition, implementing the test thread evaluation introduces another source of errors that may be introduced into the software code.
As such, there is a need for improved systems and methods for implementing software breakpoints.